Ah, I think this mostly answers a question I've had:

Given the following situation with multiple navigate event handlers:

appHistory.addEventListener('navigate', e => {
  e.respondWith(Promise.reject())
})

appHistory.addEventListener('navigate', e => {
  e.respondWith((async () => {
    doPotentiallyExpensiveWork()
    // for API calls there is `e.signal`, so that case is covered
  }))
})

I had been wondering if the second event handler could somehow get notified that the navigation was cancelled and avoid calling doPotentiallyExpensiveWork()

But if I understand this change correctly, a rejected promise in respondWith will still navigate to the url; so doPotentiallyExpensiveWork() is still useful there (as opposed to how the spec, before this PR, was to "roll back" the navigation and render the work done in doPotentiallyExpensiveWork() useless).

Does that sound correct?

Yeah, that's another good point in favor of this less-complicated design! Although I'll admit that generally dealing with multiple concurrent or queued-up navigations is still a bit up in the air; we have some idea that signal will cancel ongoing ones, but the issues in #10, #11, and #13 are not yet resolved.